\chapter{Loader \& Report Editor}\label{ch:treeChapter}

Un exemple de fichier de configuration est disponible à l'annexe \ref{load_example}. Néanmoins, ceci est un exemple simple et ne couvre qu'une petite portion des différentes balises disponibles. De plus, l'équipe de PRISME rajoute ponctuellement de nouvelles balises pour fournir de nouveaux services. Enfin, le problème se pose de la même façon pour le \reportName qui lui aussi nécessite un fichier de configuration spécifique.

De ces différentes raisons a émané le besoin d'un outil permettant d'analyser "tout" fichier XML et de fournir des services particuliers pour des balises spécifiés. 

Vu que l'on souhaite offrir une interface de configuration graphique pour certaines balises, et offrir des possibilités de manipulation de notre XML complètes, le choix s'est tourné vers une combinaison d'un affichage de notre XML en arborescence sur notre droite et d'une zone dynamique permettant la visualisation de l'élément sélectionné. On a donc un comportement standard, type explorateur de fichiers.

Pour répondre à ces différents besoins, un modèle composé de design pattern décorateur et fabrique abstraite a été mis en place tel que décrit ci-après.

\section{Builder}

Le builder est l'outil qui va nous permettre d'interpréter nos données vers notre arborescence d'objet \textit{InterpretorNode}. En fonction du format d'entrée, la classe de Builder se doit de changer et l'on doit adapter la lecture pour arriver à lire les diverses représentation de nos fichiers. De ce fait, on retrouve notre pattron "Fabrique abstraite"~\cite{fabriqueBib} autour de ces fonctionnalités. La construction des objets étant assurés par l'api \textit{Java Reflection}.

Par exemple, l'algorithme de \textit{BuilderXml} est basé sur l'api de lecture de document XML \textit{SAX} et peut etre modéliser comme suit. 

\begin{lstlisting}[label=algo_BuilderXml,caption=Algorithme de lecture de \textit{BuilderXml}]
Variable NoeudParent, NoeudCourant;

Pour chaque Noeud XML n du Document
	Si le nom de la balise courante n possede une classe Interpretor correspondante
		alors 	NoeudCourant = nouvel objet Interpretor correspondant
				On l'attache a NoeudParent
	Sinon
		Si le NoeudParent est capable d'interpreter la balise courante
			alors NoeudParent interprete la balise courante.
		Sinon 
			NoeudCourant = nouvel objet InterpretorNodeDefault
			On l'attache a NoeudParent
\end{lstlisting}

Les objets Builder possède également le chemin du package dans lequel il peut rechercher les classes correspondantes aux balises. La correspondance entre notre classe et la balise est obtenue en recherchant la classe ayant comme appellation :
\[ Name = Interpretor + TagBalise \]

Le \textit{BuilderJson} possède un algorithme légèrement différent puisque la source est architecturé pour s'adapter avant tout à son utilisation au sein de \textit{jstree.js}~\cite{jstreeBib} comme expliqué \ref{jstree}. Néanmoins les concepts de construction sont inchangés.

\section{Interpretor}

L'objet interpreteur (classe \textit{Interpretor}) centralise les méthodes d'écriture et de lecture pour chacune des balises que l'on souhaite travailler, comme on peut le voir figure \ref{inodeVisu}. Il permet aussi de visualiser l'arborescence qu'aura notre fichier final en gérant ses fils et son père (cf diagramme \ref{treeviewModelUml}).

On retrouve, de ce fait, le design pattern "decorateur"~\cite{decorateurBib} qui nous permet d'attacher dynamiquement de nouvelles responsabilités à un objet. Permettant de répondre aux besoins spécifiques des lectures et écritures de nos objets.

\begin{figure}
\centering
\includegraphics[scale=0.7]{../img/inodeDiag.jpg}
\caption{Entrées/Sortie Treeview model}
\label{inodeVisu}
\end{figure}



\paragraph{Sortie XML}

Le fichier XML produit se doit d'être lisible par les outils PRISME et respecte donc leur convention. Chaque définition d'interpreteur porte donc sa méthode d'écriture XML qui est donc à définir par le développeur. On peut à tout moment reconstruire notre élément avec el fichier produit via notre BuilderXml.

\paragraph{Sortie JSON}\label{jstree}

Suite à la décision de réaliser un panel gauche sous forme de treeview, l'outil \textit{jstree.js}~\cite{jstreeBib} a été choisi. Celui-ci offre la possibilité de créer un affichage treeview depuis une entrée html, xml ou json. Le format xml étant néanmoins contraint par certaines fonctionnalités de l'api, il aurait été perturbant d'avoir 2 format XML différents pour un même interpreteur. De plus, le format JSON est plus adapté à des communications dynamique via AJAX et est simple à appréhender comme on peut le voir listing \ref{json_example}. De même, le BuilderJSON va nous permettre de reconstruire notre interpreteur à partir de notre objet json.

On notera également que \textit{jstree.js} sauvegarde notre objet json sous l'élément principal qui lui sert à créer la représentation en arborescence. On peut donc à tout moment accéder et récupérer celui-ci via les api fourni par la librairie.

\paragraph{Sortie HTML}

La sortie HTML correspond à la représentation de notre interpreteur au sein de notre interface et ne correspond ici qu'à ce qui sera affiché dans notre partie droite. Néanmoins, notre objet étant stocké côté utilisateur au sein de notre TreeView, les différentes configurations offertes à l'utilisateur au sein de ce panel doivent être répercutées sur notre objet. De ce fait, à chaque comportement de configuration que l'on souhaite créer il faut adjoindre un bout de code JavaScript permettant de retranscrire les modifications sur notre objet (vers le json).

\section{Outils génériques}

Plusieurs outils ont été mis en place pour l'ensemble de nos éditeurs.

\subsection{qTip} 
Le plus commun est un outil de démonstration/scénario disponible via un bouton "aide" en haut à droite. Celui-ci réalisé via l'outil \textit{qTip.js}~\cite{qtipBib} permet via un overlay de faire une démonstration étape par étape de notre page, tout en réalisant des actions d'auto-complétion sur notre page. Il suffit de réimplémenter une fonction et de définir notre schéma d'étape pour cela.

\subsection{Sauvegarde Svn}

L'ensemble des fichiers sont crées sur le serveur de développement puis commités sur le svn \nomproj. L'api qui réalise la compatibilité avec svn est nommé SvnKit~\cite{svnkitBib}. Ceci permet d'avoir accès à l'ensemble de nos fichiers dès leur création et de pouvoir les déployer rapidement sur le serveur de production si souhaité. Un identifiant standard est utilisé pour l'ensemble des sauvegardes et on spécifie l'auteur de la nouvelle version via les commentaires svn en récupérant l'adresse ip de la machine cliente (header de notre requête HTTP).

\subsection{CodeMirror.js}

Lorsque l'on as besoin de réaliser une édition de code, disposer simplement du comportement des zones de texte peut être insuffisant. Pour répondre à ce besoin, l'outil \textit{CodeMirror} est utilisé~\cite{codemirrorBib}. Celui-ci affiche en particulier les numéros de ligne ou permet encore de rajouter des raccourcis clavier pour reproduire les comportements d'éditeurs de texte connus tel que Vim ou emacs.


\section{Loader Editor}

Une fois notre modèle prêt, on peut donc facilement implémenter notre interface souhaité pour le \loaderName comme le montre la vue \ref{loader1}.

\begin{figure}
\centering
\includegraphics[scale=0.9]{../img/impEcr/loader1.jpg}
\caption{Aperçu de l'interface Loader Editor}
\label{loader1}
\end{figure}

\paragraph{Zone de configuration d'élément}

Cette zone correspond à la sortie HTML de l'interpreteur couramment sélectionné. Celle-ci va donc nous permettre d'assister l'utilisateur dans la paramétrisation spécifique de notre balise. De ce fait, il est généralement nécessaire d'adjoindre à notre interface des comportements dynamiques JavaScript, tout particulièrement  l'ensemble des choix effectués par l'utilisateur dans cette zone doivent être directement retranscrit au sein de notre modélisation TreeView. 

\paragraph{Zone Treeview}

Au sein de cette zone, on retrouve la modélisation en arborescence offerte par \textit{jstree.js} et offre les manipulations basiques classiques des arborescences. On as également quelques boutons disposés au-dessus qui permettent de rajouter un élément ou de supprimer un noeud.

\paragraph{Modes d'édition}

Etant donné le caractère "brique" du moteur, l'ensemble des fonctionnalités du moteur PRISME n'est pas encore couverte, de même certaines fonctionnalités ne seront surement jamais rendues accessibles aux utilisateurs "lambda" et n'auront donc pas d'assistant de configuration. Néanmoins, pouvoir autoriser les utilisateurs à utiliser des éléments pointus et spécifiques sans obliger l'utilisateur à ouvrir un éditeur de texte et à déposer son fichier sur le serveur de développement est une obligation. De ce fait, un mode d'édition manuel du fichier complet est ouvert évitant ainsi de brider notre fichier de sortie.

\section{Report Editor}

On va donc maintenant s'occuper de la partie gérant les rapports et leur affichage. On va créer un nouveau package contenant nos nouveaux interpreteurs dédiés à notre projet \reportName. L'image \ref{report1} présente la configuration d'une requete sur une table \textit{Star} préalablement définie par notre ETL qui servira ensuite à remplir les différents graphiques que l'on souhaite présenter.

\paragraph{Modes d'édition}

Tout comme le \loaderName, nous disposons d'un mode d'édition manuel de notre document. Le mode \textit{Html Preview} quant à lui permet de visualiser le rendu du fichier en cours. On pourra noter une particularité technique de l'élément. En effet, la page est chargé dans une iFrame nous permettant ainsi d'avoir un comportement isolé et d'éviter de potentiels collisions de règles css ou de fonctions JavaScript. Néanmoins, pour éviter que l'utilisateur ne puisse naviguer ou il le souhaite depuis cette iFrame, l'ensemble des liens sont désactivés.

\begin{figure}
\centering
\includegraphics[scale=0.7]{../img/impEcr/report2.png}
\caption{Aperçu de l'interface Report Editor}
\label{report1}
\end{figure}




